讀完這一章，你會知道如何把「我想做一個網站」轉成 Lovable 可以穩定執行的產品規格。你會學到 提示詞不只是命令 AI 的句子，而是一種壓縮版 spec：它要說明目標、使用者、畫面、資料、流程、限制、角色、驗收方式，以及哪些東西現在不要做。
這一章會建立後面全書的 提示詞寫法。後面不管是 Plan Mode、Build Mode、Supabase、Paddle、Email、AI、GitHub、Testing、Security、Publish，本質上都需要你把需求講清楚。
Lovable 很快。這是優點，也是風險。
當工具可以很快生成結果時，人最容易跳過思考。你會想：「先叫它做做看，不喜歡再改。」這對小 UI（使用者介面）也許可行，但對 full-stack app 會很快失控。登入、資料庫、金流、權限、API、email、AI、publish 這些功能一旦混在模糊提示詞裡，Lovable 仍然可能做出東西，但你不一定知道它做了什麼，也不一定知道風險在哪裡。
好的提示詞不是比較華麗的文字。好的提示詞是讓 Lovable 更接近工程夥伴，而不是猜謎遊戲。
這一章的核心觀念是：
提示詞 = 目標 + 上下文 + 範圍 + 限制 + 驗收
少了目標，Lovable 不知道要優化什麼。少了上下文，它只能猜。少了範圍，它會做太多。少了限制，它可能改到你不想動的地方。少了驗收，你很難判斷結果是否完成。
在 Lovable 文件裡，prompting best practices 的第一個大方向就是先規劃。這點很樸素，但非常關鍵。
打開 Lovable 前，先回答四個問題：
例如，你想做「AI 履歷健檢工具」。模糊提示詞可能是：
請建置一個 AI 履歷健檢應用程式。
更好的起點是：
我想為台灣初階工程師建置一個 AI 履歷健檢應用程式。
使用者的主要目標是上傳或貼上履歷，取得實用的改善建議。
第一版應聚焦一個核心動作：提交履歷文字並取得結構化回饋。
建置前，請協助我定義 MVP 的範圍、頁面、使用者流程、資料需求和風險。
先不要寫程式碼。
差別不在文字長度，而在決策密度。第二個 提示詞讓 Lovable 知道目標使用者、核心行為、第一版範圍，以及目前要先規劃。
圖 3-1：結構化提示詞不是單句命令，而是把產品範圍、資料需求、整合與交付條件放進同一份可審查的規格。
很多失敗 提示詞都長這樣：
請新增登入、儀表板、付款、AI 對話、管理後台、部落格、SEO 和數據分析。
這種 提示詞看起來很具體，其實很危險。它列了功能，但沒有說產品。Lovable 知道要加很多東西，卻不知道每個東西服務什麼目標，也不知道優先順序。
比較好的方式是先寫產品，再寫功能。
我正在為台灣個人創作者建置一個付費 AI 寫作助理。
第一個付費版本應協助使用者把零散筆記整理成完整的 LinkedIn 貼文。
核心使用者流程：
1. 使用者登入。
2. 使用者輸入零散筆記。
3. 使用者選擇語氣：專業、輕鬆或具說服力。
4. 應用程式產生草稿。
5. 付費使用者可以儲存草稿。
這個步驟只規劃產品流程和資料模型。
暫時不要建置付款功能。
這個提示詞裡，login、AI、payment、data 都有位置，但它們不再是散裝功能，而是服務同一個產品行為。
Lovable 可以幫你做很多事，但第一版不該做所有事。
你應該明確寫出：
例如：
請只建置第一版。
請包含：
- 產品介紹頁
- 電子郵件潛在客戶表單
- 送出後的感謝狀態
- 適合行動裝置的版面
不要包含：
- 登入
- 付款
- AI API 呼叫
- 管理員儀表板
- 資料庫整合
目標是在建置完整產品前驗證產品訊息並收集潛在客戶資料。
「不要做什麼」很重要。很多人只寫 include，不寫 exclude。結果 Lovable 可能基於常見產品模式，自動加了你還沒準備好的功能。尤其是登入、金流、資料庫、權限，太早加入會增加 debug 成本。
Lovable 的 prompting 文件建議用 component 或 brick 的方式建構。這不是只針對 UI（使用者介面），也適用於產品功能。
一個產品可以拆成：
如果你一次要求 Lovable 做完整產品，它需要同時決定太多事。拆成 bricks 後，每次改動變小，也比較容易測試。
不好的提示詞：
請建置整個 SaaS 應用程式，包含登入、付款、儀表板、AI 內容產生和設定。
比較好的拆法：
我們會把這個應用程式拆成數個功能磚來建置。
功能磚 1：包含潛在客戶表單的產品介紹頁。
功能磚 2：身分驗證。
功能磚 3：使用模擬資料的儀表板框架。
功能磚 4：AI 內容產生流程。
功能磚 5：Paddle 付款解鎖。
功能磚 6：正式上線檢查。
目前只實作功能磚 1。
先不要加入其他功能磚。
這種寫法讓 Lovable 知道全局方向，也知道當下邊界。
Placeholder 是設計的敵人。Feature 1、Lorem ipsum、Button 這種文字看起來省事，但會讓 Lovable 失去判斷依據。
真實內容會帶來限制。標題多長、CTA 是不是清楚、卡片高度會不會爆掉、手機版是否可讀，這些都要靠真實內容才看得出來。
不好的提示詞：
請建立主視覺區塊，包含標題、副標題和按鈕。
比較好的提示詞：
請為 AI 寫作助理建立主視覺區塊。
標題：「把零散想法變成可發布的文章」
說明文字：「專為台灣創作者設計，幫你把語音筆記、草稿和靈感整理成清楚、有節奏的社群貼文。」
主要行動呼籲：「加入早鳥名單」
次要行動呼籲：「查看範例」
請採用聚焦、有編輯感且值得信任的視覺風格。
這不是文案潔癖，而是讓 layout 有真實約束。
一旦產品有多種使用者，提示詞裡一定要寫角色。否則 Lovable 可能把 admin 和一般 user 的行為混在一起。
例如：
這個應用程式有兩種角色：
- 創作者：可以產生及儲存文章草稿。
- 管理員：可以查看使用者帳號和使用量指標。
這次任務只更新創作者儀表板。
不要新增或修改管理員頁面。
創作者不應看到管理指標。
角色描述要包含：
後面做到 Supabase、RLS（Row Level Security，列層級安全）、Paddle entitlements、internal tools 時，這種寫法會救你很多次。
Lovable 能跨檔案修改，這是優點。但如果需求不清楚，它可能改到你不想動的地方。
Guardrails 是你寫在 提示詞裡的護欄。例如：
請更新產品介紹頁上的價格方案區塊。
不要修改主視覺區塊。
不要修改身分驗證邏輯。
除非必要，不要編輯共用版面元件。
如果你認為必須修改共用元件，請先說明原因再動手。
Guardrails 尤其適合：
你不是要限制 Lovable 的能力，而是要降低 collateral damage。
有時候你自己也還沒想清楚。這時候最好的提示詞不是裝懂，而是請 Lovable 先問問題。
我想在這個應用程式中新增推薦獎勵機制。
在規劃或建置前，請先提出必要問題，確認你已充分理解商業規則、使用者流程、詐騙風險和資料需求。
先不要寫程式碼。
這種 提示詞很適合複雜功能。好的 agentic workflow（工作流） 不是每次都馬上執行，而是知道什麼時候該停下來釐清。
圖 3-2：需求與現況不一致時，Lovable 先提出可選路徑並說明每條路的交付範圍，避免直接修改尚未確認的功能。
沒有驗收條件，你就只能靠感覺判斷 Lovable 有沒有完成。
驗收條件可以很簡單：
驗收標準：
- 頁面可在行動裝置和桌面裝置正常使用。
- 表單會驗證空白或格式錯誤的電子郵件地址。
- 成功送出後，使用者會看到感謝訊息。
- 主視覺文案維持不變。
- 不新增登入或付款功能。
這些條件可以讓 Lovable 在完成後自我檢查，也讓你 review 時有清單。
圖 3-3：驗收結果應對照規格逐項給出證據。這個例子沒有把「能預覽」當成完成，而是明確指出缺口與阻擋上線的項目。
Debug 時，人最容易寫出模糊提示詞：
所有功能都不能用，請修好。
這種 提示詞幾乎沒有資訊。比較好的 debug（除錯）提示詞要包含：
例如：
/landing 頁面的潛在客戶表單在上次修改後無法送出。
預期行為：使用者輸入姓名和電子郵件，按下送出後會看到感謝訊息。
實際行為：按鈕持續顯示載入中。
請先在 Plan Mode 中調查。
請檢查可能原因，並在修改程式碼前說明根本原因。
不要修改無關區塊。
如果有錯誤訊息，直接附上：
以下是主控台錯誤訊息：
[貼上錯誤訊息]
請以簡單易懂的方式說明這段訊息的意思。
找出根本原因，並建議最小且安全的修正方式。
先不要修改程式碼。
Debug 提示詞的目標不是「讓 AI 猜」，而是提供足夠證據讓它分析。
Lovable 文件提到兩種常見 build style。
第一種是 frontend（前端）first。先用 mock data 做畫面、流程和基本互動。等產品體驗穩定後，再接 Lovable Cloud 或 Supabase。這比較適合初學者，因為你可以避免太早碰資料庫 schema、SQL、RLS（Row Level Security，列層級安全）、edge functions。
第二種是 back-to-front。從一開始就接 backend（後端），一個功能一個功能做真實資料。這適合比較有經驗、也願意處理 debug 的人。
本書建議大多數讀者先用 frontend（前端）first：
請採用前端優先的方式建置這個儀表板，先使用模擬資料。
暫時不要連接資料庫。
請先完成版面、篩選器、空白狀態和行動裝置上的互動行為。
等我確認使用者介面流程後，再連接 Supabase。
這會讓你先把產品體驗做對，再處理資料持久化。
我想建置 [產品名稱]。
目標使用者是 [具體使用者族群]。
使用者要達成的主要成果是 [使用者能完成的事情]。
第一版範圍：
- [功能一]
- [功能二]
- [功能三]
目前不包含：
- [排除功能一]
- [排除功能二]
建置前，請把以上內容整理成精簡的產品規格。
請包含使用者旅程、頁面、資料模型、整合項目、風險和待確認問題。
先不要寫程式碼。
這適合從 idea 進入 Plan Mode。
請只建置 [元件或區塊名稱]。
目的：
[這個元件協助使用者完成什麼]
內容：
- 標題：[實際標題]
- 說明：[實際說明]
- 行動呼籲：[實際行動呼籲]
設計方向：
[視覺風格]
限制：
- 不要修改 [既有區塊或元件]。
- 不要加入後端邏輯。
- 行動版版面必須容易閱讀。
驗收標準：
- [標準一]
- [標準二]
- [標準三]
這適合 UI（使用者介面）和 landing page 章節。
這次變更會影響容易出錯的區域：[身分驗證／付款／資料庫／共用版面]。
修改前：
- 檢查相關檔案和相依項目。
- 說明實作方式。
- 指出可能受到影響的功能。
實作限制：
- 不要修改無關檔案。
- 保留 [角色或流程] 的既有行為。
- 如果必須修改共用元件，請先說明原因。
任務：
[具體任務]
驗證方式：
- [測試或流程一]
- [測試或流程二]
這適合登入、金流、權限、資料表、production（正式上線）設定。
[頁面／功能／流程] 發生問題。
預期行為：
[應該發生的行為]
實際行為：
[實際發生的行為]
背景：
- 問題出現在 [變更或時間] 之後。
- 我已經嘗試過 [嘗試過的方法]。
- 相關錯誤或紀錄：[如有請貼上]
請先調查。
請說明最可能的根本原因，並建議最小且安全的修正方式。
等我核准後再修改程式碼。
這適合避免陷入 Try to Fix 迴圈。
拿上一章的 AI Writer Landing 專案，先不要加功能。這次只做 提示詞規格練習。
任務：
你應該產出三份 提示詞：
完成後，檢查每份 提示詞是否包含：
「做得高級一點」、「讓它更好看」、「加一個完整後台」都不是規格。你要說清楚高級是什麼，後台給誰用，要看什麼資料，要能做什麼。
一次 提示詞裡同時改 landing page、登入、付款、資料表、AI API，很難 review，也很難 debug。拆成 bricks。
Lovable 可能會基於常見產品模式補功能。這有時候很方便，但在早期 scope control 裡會造成混亂。
Placeholder 會讓 layout 看起來暫時合理，等真實文案放進去才爆掉。從一開始就用接近真實的文案。
描述 expected behavior 和 actual behavior。能貼 log 就貼 log。不能貼 log，也要說出頁面、流程、操作步驟和最近變更。
讀完本章後，建議用自己的專案情境繼續追問 Lovable 或本書作者：
嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。
如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：
📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。
📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。
🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。
如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！
🎁 免費送 Lovable 額度給讀者！
我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。
參加方式：
確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！
iThome鐵人賽
看影片追技術